home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000083_owner-urn-ietf _Thu Nov 7 04:38:35 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA24682 for urn-ietf-out; Thu, 7 Nov 1996 04:38:35 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA24677 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 04:38:32 -0500
  3. Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA18638  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 04:38:25 -0500
  5. Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Thu, 7 Nov 1996 09:37:38 +0000
  6. Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 7 Nov 1996 09:37:19 +0000
  7. Received: from Ant.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Thu, 7 Nov 96 09:36:25 GMT
  8. Message-Id: <2.2.32.19961107093626.006c2f7c@sherekhan.jungle.bt.co.uk>
  9. X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk
  10. X-Mailer: Windows Eudora Pro Version 2.2 (32)
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset="us-ascii"
  13. Date: Thu, 07 Nov 1996 09:36:26 +0000
  14. To: Renato Iannella <renato@dstc.edu.au>
  15. From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  16. Subject: Re: Re[2]: [URN] Resolution Services (N2L etc)
  17. Cc: urn-ietf@bunyip.com
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. At 10:13 07/11/96 +1000, Renato Iannella wrote:
  24. >Bob Briscoe <rbriscoe@jungle.bt.co.uk> wrote:
  25. >> If you insist, for instance, that the URC and the resource both have the
  26. >> same URN, you are mandating that a URC must be authored with the permission
  27. >> of the same domain of authority as the author of the resource itself (or
  28. >> vice versa). This stops people *independently* publishing URCs about other
  29. >> people's resources. Now where would the Web be today if you had to get
  30. >> someone's permission to link to them?
  31. >
  32. >I get a good feeling knowing that if I resolve a URN, I will
  33. >get back a URC describing that resource, created and maintained
  34. >by the owners (or their agents) - and not a third party
  35. >review of the resource. If I wanted that, then I would go
  36. >to such a service provider.
  37. >
  38. >If I publish a URN like <urn:inet:dstc.edu.au:rdu/tr009>
  39. >which points to a Technical Report at the DSTC - you can 
  40. >quote it in a Web Page - and like everything - I can only
  41. >guarantee that it will last the lifetime of the DSTC.
  42. >
  43. >If you wish to provide a review of that Technical Report
  44. >(via a URC or whatever) then you are free to, and to allocate
  45. >you own URN, say <urn:inet:bt.co.uk:review:rdu/tr009>.
  46. >
  47.  
  48. So now, the URN resolution service is doing authentication of metadata too!
  49.  
  50. Whoaaaa! There are so many assumptions flying around this working group that
  51. aren't documented in the framework.
  52.  
  53. Hadn't you better look at your security if this is a goal? What if my URC
  54. describes my payment service and says it only charges 2% commission when in
  55. fact it charges 20%? Would the user be able to claim that this unsigned
  56. information misled them into using your payment service on the basis that it
  57. was the authentic metadata tied to the payment service via DNS (rather than
  58. someone else's possibly innocently out of date information)? Would a good
  59. lawyer be able to prove DNS could have been compromised and get the payment
  60. service operator off the hook? Yes.
  61.  
  62. Why don't you just keep it simple. URNs are a base building block. If you
  63. just stick to name to address mapping, it's less likely to break in the future.
  64.  
  65. If you want to authenticate metadata, the (now expired) drafts on URCs (e.g.
  66. Ron Daniel's URC Scenarios and requirements
  67. http://www.acl.lanl.gov/URI/Scenarios/scenarios_3.asc ) proposes signing the
  68. metadata which would also be able to tie the resource to the URC by
  69. reference so you could find it from the URC's name).
  70.  
  71. >I don't wish to allocate a URN _directly_ to the Technical
  72. >Report - because I reserve the right to move it around our
  73. >network and to change its form.
  74.  
  75. Don't see the problem - that's what URNs are for.
  76. 1. If you had a URN for the URC and an URN for the resource, the URC would
  77. just have to refer to the resource's URN.
  78. 2. You could just have a URN for the URC which would refer to the resource
  79. addresses directly and be the thing you update if the resources move around
  80. 3. You could just have a URN for the resources of you didn't want to bother
  81. with URCs
  82.  
  83. What I was complaining about is the apparent assumption that the same URN
  84. would be used for both URN and URC and one would have to say N2C if you
  85. wanted the former, and N2L for the latter.
  86.  
  87. What if BT want to sub-contract our resource description to a trusted third
  88. party so customers find it *more* believable than our own advertisements?
  89. The TTP might be willing to take liability for their descriptions but don't
  90. want the hassle of co-ordinating every URN registration with me?
  91.  
  92. Ron's proposal: DSTC happy, BT happy.
  93. Your proposal: DSTC happy, BT sad.
  94.  
  95. I would prefer there to be as near to zero assumptions as to how people
  96. might want to use URNs as possible.
  97.  
  98. Bob
  99. ____________________________________________________________________________
  100. Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm
  101.